3. Fragmentation and Path MTU Discovery
Sometimes an LSR may receive a labeled packet over a PPP or a LAN
link, and may need to send it out, say, an LC-ATM interface. Then
the incoming packet will be received using the encapsulation
specified in this document, but the outgoing packet will not be sent
using the encapsulation specified in this document. In this case,
the procedure for carrying the value of the "outgoing TTL" is
determined by the procedures used for carrying labeled packets on,
e.g., LC-ATM interfaces.
3. Fragmentation and Path MTU Discovery
Just as it is possible to receive an unlabeled IP datagram which is
too large to be transmitted on its output link, it is possible to
receive a labeled packet which is too large to be transmitted on its
output link.
It is also possible that a received packet (labeled or unlabeled)
which was originally small enough to be transmitted on that link
becomes too large by virtue of having one or more additional labels
pushed onto its label stack. In label switching, a packet may grow
in size if additional labels get pushed on. Thus if one receives a
labeled packet with a 1500-byte frame payload, and pushes on an
additional label, one needs to forward it as frame with a 1504-byte
payload.
This section specifies the rules for processing labeled packets which
are "too large". In particular, it provides rules which ensure that
hosts implementing Path MTU Discovery [4], and hosts using IPv6
[7,8], will be able to generate IP datagrams that do not need
fragmentation, even if those datagrams get labeled as they traverse
the network.
In general, IPv4 hosts which do not implement Path MTU Discovery [4]
send IP datagrams which contain no more than 576 bytes. Since the
MTUs in use on most data links today are 1500 bytes or more, the
probability that such datagrams will need to get fragmented, even if
they get labeled, is very small.
Some hosts that do not implement Path MTU Discovery [4] will generate
IP datagrams containing 1500 bytes, as long as the IP Source and
Destination addresses are on the same subnet. These datagrams will
not pass through routers, and hence will not get fragmented.
Unfortunately, some hosts will generate IP datagrams containing 1500
bytes, as long the IP Source and Destination addresses have the same
classful network number. This is the one case in which there is any
risk of fragmentation when such datagrams get labeled. (Even so,
fragmentation is not likely unless the packet must traverse an
ethernet of some sort between the time it first gets labeled and the
time it gets unlabeled.)
This document specifies procedures which allow one to configure the
network so that large datagrams from hosts which do not implement
Path MTU Discovery get fragmented just once, when they are first
labeled. These procedures make it possible (assuming suitable
configuration) to avoid any need to fragment packets which have
already been labeled.
3.1. Terminology
With respect to a particular data link, we can use the following
terms:
- Frame Payload:
The contents of a data link frame, excluding any data link
layer headers or trailers (e.g., MAC headers, LLC headers,
802.1Q headers, PPP header, frame check sequences, etc.).
When a frame is carrying an unlabeled IP datagram, the Frame
Payload is just the IP datagram itself. When a frame is
carrying a labeled IP datagram, the Frame Payload consists of
the label stack entries and the IP datagram.
- Conventional Maximum Frame Payload Size:
The maximum Frame Payload size allowed by data link standards.
For example, the Conventional Maximum Frame Payload Size for
ethernet is 1500 bytes.
- True Maximum Frame Payload Size:
The maximum size frame payload which can be sent and received
properly by the interface hardware attached to the data link.
On ethernet and 802.3 networks, it is believed that the True
Maximum Frame Payload Size is 4-8 bytes larger than the
Conventional Maximum Frame Payload Size (as long as neither an
802.1Q header nor an 802.1p header is present, and as long as
neither can be added by a switch or bridge while a packet is in
transit to its next hop). For example, it is believed that
most ethernet equipment could correctly send and receive
packets carrying a payload of 1504 or perhaps even 1508 bytes,
at least, as long as the ethernet header does not have an
802.1Q or 802.1p field.
On PPP links, the True Maximum Frame Payload Size may be
virtually unbounded.
- Effective Maximum Frame Payload Size for Labeled Packets:
This is either the Conventional Maximum Frame Payload Size or
the True Maximum Frame Payload Size, depending on the
capabilities of the equipment on the data link and the size of
the data link header being used.
- Initially Labeled IP Datagram:
Suppose that an unlabeled IP datagram is received at a
particular LSR, and that the the LSR pushes on a label before
forwarding the datagram. Such a datagram will be called an
Initially Labeled IP Datagram at that LSR.
- Previously Labeled IP Datagram:
An IP datagram which had already been labeled before it was
received by a particular LSR.
3.2. Maximum Initially Labeled IP Datagram Size
Every LSR which is capable of
a) receiving an unlabeled IP datagram,
b) adding a label stack to the datagram, and
c) forwarding the resulting labeled packet,
SHOULD support a configuration parameter known as the "Maximum
Initially Labeled IP Datagram Size", which can be set to a non-
negative value.
If this configuration parameter is set to zero, it has no effect.
If it is set to a positive value, it is used in the following way.
If:
a) an unlabeled IP datagram is received, and
b) that datagram does not have the DF bit set in its IP header,
and
c) that datagram needs to be labeled before being forwarded, and
d) the size of the datagram (before labeling) exceeds the value of
the parameter,
then
a) the datagram must be broken into fragments, each of whose size
is no greater than the value of the parameter, and
b) each fragment must be labeled and then forwarded.
For example, if this configuration parameter is set to a value of
1488, then any unlabeled IP datagram containing more than 1488 bytes
will be fragmented before being labeled. Each fragment will be
capable of being carried on a 1500-byte data link, without further
fragmentation, even if as many as three labels are pushed onto its
label stack.
In other words, setting this parameter to a non-zero value allows one
to eliminate all fragmentation of Previously Labeled IP Datagrams,
but it may cause some unnecessary fragmentation of Initially Labeled
IP Datagrams.
Note that the setting of this parameter does not affect the
processing of IP datagrams that have the DF bit set; hence the result
of Path MTU discovery is unaffected by the setting of this parameter.
3.3. When are Labeled IP Datagrams Too Big?
A labeled IP datagram whose size exceeds the Conventional Maximum
Frame Payload Size of the data link over which it is to be forwarded
MAY be considered to be "too big".
A labeled IP datagram whose size exceeds the True Maximum Frame
Payload Size of the data link over which it is to be forwarded MUST
be considered to be "too big".
A labeled IP datagram which is not "too big" MUST be transmitted
without fragmentation.
3.4. Processing Labeled IPv4 Datagrams which are Too Big
If a labeled IPv4 datagram is "too big", and the DF bit is not set in
its IP header, then the LSR MAY silently discard the datagram.
Note that discarding such datagrams is a sensible procedure only if
the "Maximum Initially Labeled IP Datagram Size" is set to a non-zero
value in every LSR in the network which is capable of adding a label
stack to an unlabeled IP datagram.
If the LSR chooses not to discard a labeled IPv4 datagram which is
too big, or if the DF bit is set in that datagram, then it MUST
execute the following algorithm:
1. Strip off the label stack entries to obtain the IP datagram.
2. Let N be the number of bytes in the label stack (i.e, 4 times
the number of label stack entries).
3. If the IP datagram does NOT have the "Don't Fragment" bit set
in its IP header:
a. convert it into fragments, each of which MUST be at least N
bytes less than the Effective Maximum Frame Payload Size.
b. Prepend each fragment with the same label header that would
have been on the original datagram had fragmentation not
been necessary.
c. Forward the fragments
4. If the IP datagram has the "Don't Fragment" bit set in its IP
header:
a. the datagram MUST NOT be forwarded
b. Create an ICMP Destination Unreachable Message:
i. set its Code field [3] to "Fragmentation Required and DF
Set",
ii. set its Next-Hop MTU field [4] to the difference between
the Effective Maximum Frame Payload Size and the value
of N
c. If possible, transmit the ICMP Destination Unreachable
Message to the source of the of the discarded datagram.
3.5. Processing Labeled IPv6 Datagrams which are Too Big
To process a labeled IPv6 datagram which is too big, an LSR MUST
execute the following algorithm:
1. Strip off the label stack entries to obtain the IP datagram.
2. Let N be the number of bytes in the label stack (i.e., 4 times
the number of label stack entries).
3. If the IP datagram contains more than 1280 bytes (not counting
the label stack entries), or if it does not contain a fragment
header, then:
a. Create an ICMP Packet Too Big Message, and set its Next-Hop
MTU field to the difference between the Effective Maximum
Frame Payload Size and the value of N
b. If possible, transmit the ICMP Packet Too Big Message to the
source of the datagram.
c. discard the labeled IPv6 datagram.
4. If the IP datagram is not larger than 1280 octets, and it
contains a fragment header, then
a. Convert it into fragments, each of which MUST be at least N
bytes less than the Effective Maximum Frame Payload Size.
b. Prepend each fragment with the same label header that would
have been on the original datagram had fragmentation not
been necessary.
c. Forward the fragments.
Reassembly of the fragments will be done at the destination
host.
3.6. Implications with respect to Path MTU Discovery
The procedures described above for handling datagrams which have the
DF bit set, but which are "too large", have an impact on the Path MTU
Discovery procedures of RFC 1191 [4]. Hosts which implement these
procedures will discover an MTU which is small enough to allow n
labels to be pushed on the datagrams, without need for fragmentation,
where n is the number of labels that actually get pushed on along the
path currently in use.
In other words, datagrams from hosts that use Path MTU Discovery will
never need to be fragmented due to the need to put on a label header,
or to add new labels to an existing label header. (Also, datagrams
from hosts that use Path MTU Discovery generally have the DF bit set,
and so will never get fragmented anyway.)
Note that Path MTU Discovery will only work properly if, at the point
where a labeled IP Datagram's fragmentation needs to occur, it is
possible to cause an ICMP Destination Unreachable message to be
routed to the packet's source address. See section 2.3.
If it is not possible to forward an ICMP message from within an MPLS
"tunnel" to a packet's source address, but the network configuration
makes it possible for the LSR at the transmitting end of the tunnel